Hmm, difficult. This seems a single purpose primitive for the moment.

I don't want to outright dismiss it, since such contributions are very valuable, but I'd rather not go through the trouble implementing it for all SOMs. I am not even sure how to do it for JavaScript.

So, perhaps asked differently, is there another important use case for the primitive?

While it's nice to see that you want to bring test coverage up, for the moment, I wonder whether this is a good tradeoff.

For your testing in SOM-rs, you may simply cheat in the interpreter and provide the primitive even though it is not explicitly defined, which could be a good middle ground for the moment.

You can implement "pause" simply using ticks: you just spin in a while loop. Obviously this is not a very good implementation, but it does at least avoid adding a primitive.

I was just proposing this because efficient waiting isn't doable in application code without support from the interpreter, so I was wondering if proposing it would spark interest for this.

If the value of this feature is considered lower compared to the effort needed to implement it in all interpreters, then I am totally fine with dropping this PR (+ I agree that it would be tricky to implement this in JS without rewriting to use async).

As pointed out by @ltratt, there is indeed a better alternative than what I wrote in the original message that I didn't think about, in order to await a specific amount of time predictably, so it is not that bad after all:

Timer = (
  wait: millis = (
    | start |
    start := system ticks / 1000.
    [ system ticks / 1000 - start < millis ] whileTrue: nil.
  )
)

And I can't think of another real use-case yet for the primitive, so yeah, feel free to close the PR.